home *** CD-ROM | disk | FTP | other *** search
/ Amiga Collections: Panorama / Panorama - Disk 17D (1987-05-27)(Pacific North-West Amigas Club)[WB].zip / Panorama - Disk 17D (1987-05-27)(Pacific North-West Amigas Club)[WB].adf / Draco < prev    next >
Text File  |  1987-05-25  |  10KB  |  225 lines
  1. Here is Draco, a "c"-like programming language which includes some of
  2. the better features of Pascal.  Included in the Draco package are all
  3. of the WB 1.2 include files (Draco-ized of course) required to compile
  4. programs on the Amiga, as well as a small support library for reading
  5. and writing files, and support routines paralleling C's string functions.
  6. There are also extensive documentation files and several example 
  7. programs both large and small.
  8.  
  9. Draco originally came on two disks.  These have been arced down to the
  10. two directories Draco.Sys and Draco.Other.  To restore the two disks
  11. you will first need to format two disks of your own called:
  12.  
  13.        "Draco Sys"  and
  14.        "Draco Other"
  15.  
  16. Then change the current directory to Draco.Sys and execute the script
  17. file MakeDraco.  Follow the same procedure for Draco.Other, but execute
  18. the script file MakeOther.
  19.  
  20. This procedure unfortunately requires two disk drives.  If you only have
  21. a single drive,  you will have to find a friend with two drives.  Failing
  22. that,  come to the next PD Party on June 12, 1987 where the original
  23. disks will be available.
  24.  
  25. The following is a brief introduction given by the author, Chris Gray
  26. which will give you a flavour of the Draco language ...
  27.  
  28. - Club Librarian,
  29.   Jeff Lydiatt.
  30.  
  31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
  32.  
  33.  
  34.  
  35.     What is Draco, Why Did I Write It and Why Is It Like It Is?
  36.  
  37.     I usually describe Draco (pronounced Dray-ko) as a "systems programming
  38. language". That means that it is a language which is suitable for what I
  39. think of as systems programming - writing operating systems, compilers,
  40. editors, databases, etc. This doesn't mean that it isn't suitable for other
  41. applications such as writing games, graphics programs, numerical programs,
  42. etc. It does mean that the language has all of the facilities needed for
  43. the former type of programming, such as bit operators, pointer
  44. manipulation, support for complex data structures, etc.
  45.  
  46.     What is different about Draco? I won't try to compare it with every
  47. other programming language in the world; instead I'll stick to two of the
  48. most popular ones for micros nowadays - C and Pascal. Draco has all of the
  49. facilities of C, except for bitfields and the macro preprocessor. Unlike C,
  50. and like Pascal, it is a strongly typed language. This means that it won't
  51. let you assign an integer to a pointer (unless you really insist). It is
  52. also not an expression language like C, thus it makes a quite strict
  53. distinction between statements like "a := 27" and expressions like "a +
  54. 27". Pascal is strongly typed, but lacks many of C's facilities - pointer
  55. manipulation, bit manipulation, standard separate compilation, conditional
  56. compilation, etc. I like to think that Draco combines the best features of
  57. both languages.
  58.  
  59.     Visually, Draco doesn't really resemble either language closely, but is
  60. a little closer to Pascal than C. It uses ':=' for assignment and '=' for
  61. comparison, like Pascal and unlike C. It's structure and union declarations
  62. are like those of C, however. As a simple comparison, here follows the same
  63. program, written in Pascal, C, and Draco:
  64.  
  65. Pascal:
  66.  
  67.     PROGRAM test(INPUT, OUTPUT);
  68.     VAR
  69.     i, j : INTEGER;
  70.     
  71.     BEGIN
  72.     FOR i := 0 TO 10 DO BEGIN
  73.         FOR j := 0 TO i DO
  74.         WRITE(j : 2, ' ');
  75.         WRITELN
  76.     END;
  77.     WRITELN("All done.")
  78.     END.
  79.  
  80. C:
  81.  
  82.     #include <stdio.h>
  83.  
  84.     main(argc, argv)
  85.     int argc;
  86.     char *argv[];
  87.     {
  88.     int i, j;
  89.     
  90.     for (i = 0; i <= 10; ++i) {
  91.         for (j = 0; j <= i; ++j)
  92.         printf("%2d ", j);
  93.         printf("\n");
  94.     }
  95.     printf("All done.\n");
  96.     }
  97.  
  98. Draco:
  99.  
  100.     proc main()void:
  101.     int i, j;
  102.     
  103.     for i from 0 upto 10 do
  104.         for j from 0 upto i do
  105.         write(j : 2, ' ');
  106.         od;
  107.         writeln();
  108.     od;
  109.     writeln("All done.");
  110.     corp;
  111.  
  112.     First, it's clear that the C program has lots of brackets, while the
  113. Pascal and Draco programs have lots of keywords. A significant difference,
  114. not very clear in this small example, is that Draco uses different keywords
  115. for each job, rather than relying on a single construct (the BEGIN - END or
  116. '{' - '}' block). I greatly prefer keywords, finding them easier on the
  117. eye. I also prefer languages in which the use of case (UPPER v.s. lower) is
  118. available for my own purposes, rather than having them equivalent as in
  119. most Pascals. Also, note that the Draco program uses 'upto' in the 'for'
  120. loops - this tells the compiler that the loop will be counting upwards;
  121. 'downto' is used for downward counting loops. C doesn't really have a
  122. semantically different 'for' loop - it's just a kind of shorthand for a
  123. 'while' loop.
  124.  
  125.     Some of the inadequacies of Pascal from my point of view are as
  126. follows:
  127.  
  128.     - no standard separate compilation
  129.     - no conditional compilation
  130.     - no general string mechanism
  131.     - no pointer manipulation
  132.     - no bit manipulation
  133.     - I HATE BEGIN and END!
  134.     - no signed/unsigned types
  135.     - limitations on function and argument types
  136.     - procedure calls don't use '()' - they look like variables
  137.     - no typed, named, constants
  138.     - no available, decent implementations (fast compilation, good
  139.         code, nice libraries, good error reporting)
  140.     - I/O semantics that are poor for interactive programs
  141.     - no file inclusion or module specification facility
  142.  
  143.     Some of the inadequacies of C from my point of view:
  144.  
  145.     - too many bloody brackets!
  146.     - horrible declaration syntax (just what is "char *(*p[])()"?)
  147.     - error prone conventions (how many times have YOU written '='
  148.         when you meant '=='?)
  149.     - non-portable I/O (if you don't believe this, take a look at the
  150.         open calls on CP/M or MS-DOS versions of C, where you get to
  151.         tell it what it's supposed to do with '\n')
  152.     - potential for extremely unreadable code (misuse of macros, etc.)
  153.     - slow compilers (as I've heard it, the reason that the original
  154.         UNIX C compiler for the PDP-11 generated assembler source was
  155.         so that the compiler writers didn't have to worry about long/
  156.         short branch optimization, since that was done by the
  157.         assembler. Producing assembler source is just plain slow. Those
  158.         who argue that they want to hand edit it to improve it are
  159.         crazy!)
  160.     - lack of much type checking (I prefer compilers that tell me about
  161.         my dumb mistakes. This is a lot better in the ANSI draft
  162.         version.)
  163.     - inefficient standard setup - passing everything as 16 bits on an
  164.         8 bit CPU isn't so hot (or 32 bits on a 16 bit one)
  165.     - stupid linkers - why add all that code I'm never calling?
  166.     - no built-in I/O - this makes even the simplest programs large
  167.     - no typed, named constants
  168.  
  169.     All of these issues have been addressed in the Draco language and
  170. tools. Just as important to me is the quality of the tools (compiler,
  171. linker, etc.) The Draco compiler goes from source code to relocatable,
  172. optimized machine code at a rate of about 2000 lines per minute on a 5 MHz
  173. 8080. Working from one 8" floppy disk, the entire compiler (about 10,000
  174. lines) can be rebuilt in under 10 minutes. No other compiler I've heard of
  175. for CP/M can do this (at least not and produce good code). The linker will
  176. link small programs in one quick pass, and won't load any code that isn't
  177. referenced by the program. A simple "hello there world" program is under
  178. 1000 bytes. The Amiga version of the compiler operates at about the same
  179. speed, and the linker I'm using (BLink) isn't bad, but doesn't selectively
  180. load like mine does.
  181.  
  182.     Another reason that these programs exist is that I LIKE writing
  183. compilers and stuff. I'm up to about seven compilers now, the latest of
  184. which is a C compiler that should meet the ANSI draft standard (it's a huge
  185. monster written in C, but at least I was paid to write it!)
  186.  
  187.     So I've written my very own personal compiler, that does things just
  188. the way I want; why should anyone else want to use it? Put simply, the
  189. Draco package (which includes the various libraries I've built up) is
  190. possibly the most effective way to produce compact, efficient code for CP/M
  191. systems. In the past couple of years, asside from fine tuning the compiler,
  192. I've written somewhere around 20,000 lines of Draco code, including the
  193. screen editor I'm typing this into, a complex graphic role-playing game,
  194. several CRT-oriented games for CP/M, ranging from the trivial to the quite
  195. complex, a database package, a text processor (with a friend), a modem
  196. program, etc. If you want to program a CP/M system, whether for fun, profit
  197. or whatever, and are willing to learn another language, then I feel that
  198. Draco is a valid choice. The Amiga version hasn't been used as much yet,
  199. but appears to be reasonably solid. I plan on bringing it up to the
  200. standard I set with the CP/M-80 version, but this will take time and a lot
  201. of work.
  202.  
  203.     To be fair, I will end this intro with a list of things that I find
  204. are lacking in this version of Draco:
  205.  
  206.     - essentially non-existant floating point support
  207.     - no proper modules (although Draco goes about half way to
  208.         providing a usable kind of module)
  209.     - no bit oriented type (I haven't yet fully convinced myself that
  210.         this is needed)
  211.     - error handling is considerably better than most C compilers I've
  212.         heard of, but it could still use some improvement
  213.     - object code can ALWAYS use improvement, but the improvements
  214.         that are left would either be difficult or of little actual
  215.         benefit and would probably make the compiler too big to fit on
  216.         standard CP/M systems. This isn't as much of a problem on the
  217.         Amiga, but I do plan on keeping the compiler small enough to
  218.         run well on a 512K machine.
  219.  
  220. and, of course
  221.  
  222.     - Draco is supported only by me, and available only on the systems
  223.         that I choose to put it on (currently CP/M-80 and Commodore
  224.         Amiga)
  225.